圖片來源：OpenTelemetry
| 資訊處理流程 | 生成 | 收集 | 儲存 | 使用 |
|---|---|---|---|---|
| OpenTelemetry Collector | ✓ |
OpenTelemetry Collector 是一個不受特定廠商限制的 Agent，用於收集與處理 Telemetry Data。它可以接收不同格式的 Telemetry Data（Traces、Metics、Logs），再將它們匯出到不同的後端。雖然直接把資料送往特定的後端，如 Tempo 或 Jaeger，可能看似沒有問題，但這樣的架構會使生成的資訊依賴於特定的後端。例如，後端出現問題或需要更換時，就必須要修改程式的設定檔，或者需要對資料進行額外的處理時，也必須要修改程式碼才能達成。
引入 Collector 之後，就達到了依賴反轉的效果。Collector 作為一個介面，位於服務與後端之間，讓服務只需將資料送往 Collector。Collector 會處理資料後再送往後端，達到解耦的效果。此外，Collector 提供了多種的 Processor，能進行資料轉換、過濾、抽樣等處理，這些都透過設定檔來完成，無需修改程式碼或重啟服務，實現了動態調整的功能。
OpenTelemetry Collector 有 Core 和 Contrib 兩個版本。Core 版本只提供最基本的功能，而 Contrib 版本則包含了各種額外的元件。例如，Routing Connector 可以依條件分派資料流向，而 Kafka Receiver 則可以從 Kafka 取得資料，這些都是在 Contrib 才提供的元件。所以在使用時，需注意所需的功能是否包含在 Core 版本內。如果不包含，則需要使用 Contrib 版本。
Collector 主要可以分為三種部署方式，在官網中有介紹了各種部署方式的優缺點，詳細可以參考 Deployment。以下為簡單的整理與介紹：
圖片來源：OpenTelemetry
增加 Collector 雖能大幅提升整體架構的彈性，但同時也提高了維運的複雜度與成本。因此，也需增加對應的監控與備援機制，以防 Collector 成為架構中的瓶頸或單點失敗點。
OpenTelemetry Collector 的設定檔採用 YAML 格式，主要用於定義資料的處理流程（pipeline）以及 Collector 的設定。設定檔大致可分為兩大類：
receivers、processors、exporters、connectors 和 extensions。這些用於宣告元件與參數，需要透過 service Section 來啟用。
/[name] 來區分，例如：otlp/trace、otlp/metrics 都是使用 otlp 這個類型的元件，但有不同的名字。core 表示在 Core 版本中可以直接使用，若只有標記 contrib 則必須使用 Contrib 版本才能使用。service，主要定義 Collector 的設定以及要執行的 pipeline。在設定檔中的樣式與詳細說明如下：
receivers:
# 宣告資料的來源元件，例如：接收 OTLP 格式的資料
otlp:
protocols:
grpc:
http:
processors:
# 宣告資料的處理元件，例如：過濾符合條件的資料
batch:
exporters:
# 宣告資料的輸出元件，例如：將資料輸出至 Tempo
otlp:
endpoint: otelcol:4317
connectors:
# 宣告資料的連接元件，它可以同時作為一個 Pipeline 的輸出與另一個 Pipeline 的來源，例如：將 A Pipeline 輸出的資料轉發至另一個 B Pipeline 的來源
forward:
extensions:
# 宣告有哪些 Collector 本身可以用的 Extension，與 Pipeline 無關，例如：Collector 的 health_check
health_check:
pprof:
zpages:
service:
# 實際定義 Collector 要啟用哪些功能以及 Pipeline 的 Section
pipelines:
# 透過前面定義的元件建立的 Pipeline
traces: # 定義一個名為 traces 的 Pipeline，會從 receivers 接收資料後，經過 processors 處理，再輸出至 exporters
receivers: [otlp]
processors: [batch]
exporters: [otlp]
telemetry:
# Collector 本身要揭露的 Telemetry Data
metrics: # 揭露 Collector 的 Metrics 在 8888 Port
level: detailed
address: 0.0.0.0:8888
extensions:
# 引用前面宣告的 Extension，讓 Extension 實際生效
- health_check
- pprof
- zpages
既然都是 OpenTelemetry Collector，最常用的輸入資料格式即是 OTLP。OTLP Receiver 能夠接收 OTLP 格式的 Traces、Metrics 和 Logs。透過設定，可以開啟不同的 Protocol 來接收資料，如：gRPC、HTTP。
receivers:
otlp:
protocols:
grpc: # 開啟 gRPC 預設為 0.0.0.0:4317
http: # 開啟 HTTP 預設為 0.0.0.0:4318
針對不同 Protocol 有其他詳細的設定，例如 CORS、TLS，可以參考官方的 Advanced Configuration。
Collector 支援多種輸出方式，例如，透過 gRPC 以 OTLP 格式輸出至 Tempo 或 Jaeger 的 OTLP gRPC Exporter。
exporters:
otlp:
endpoint: tempo:4317
tls:
insecure: true
otlp/jaeger:
endpoint: jaeger-collector:4317
tls:
insecure: true
可以看到，這裡宣告了兩個 OTLP Exporter：一個是輸出至 Tempo，另一個是輸出至 Jaeger。第一個直接命名為 otlp，第二個則是命名為 otlp/jaeger。如此便可區分不同的 Exporter，儘管它們實際上都使用了 otlp 這個類型的 Exporter。
在 Receiver 接收資料後，可以透過 Processor 進行加工，然後再透過 Exporter 進行輸出。加工的方式有多種，如過濾、轉換和抽樣等，詳細可以參考官方的 Processors。其中，官方強烈建議要啟用的是 Batch Processor：
processors:
batch:
Batch Processor 會先暫存收到的資料，當資料量達到一定數量或時間時，才會進行一次性的處理。這樣做可以減少資料傳輸次數，從而提高效能。
Service Section 是用於實際定義 Collector 行為的部分，主要包含 pipelines、extensions 和 telemetry 三個部分。
首先來看 pipelines。前面提到的 receivers、processors 和 exporters 只是宣告我們預計要使用哪些元件，而真正的啟用和組合則是在 pipelines 中定義。例如，我們想要建立一個處理 Trace 的 Pipeline，它從 otlp Receiver 接收資料後，經過 batch Processor 處理，再輸出至 otlp Exporter：
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
Pipeline 流程圖
通過上述設定，我們才實際建立了一個會被執行的資料處理流程。在每個 Pipeline 中的 receivers、processors、exporters 定義了要使用的元件，三者都可以同時使用多個元件，但要注意 processors 有多個時其順序會影響到資料的處理順序。
Pipeline 也有類型的區別，分為 traces、metrics、logs，分別對應處理不同類型的資料，這裡我們定義的是 traces，該 Pipeline 只會處理 Traces 資料。與元件一樣，Pipeline 也可以取名，一樣是在 Key 後面加上 /[name] 來區分，例如：traces/jaeger、traces/tempo，這樣就可以區分不同的 Pipeline。
Extensions 主要用於啟用 Collector 本身的擴充功能，如 health_check、pprof 和 zpages 等。這些 Extensions 需要在 extensions Section 中先行宣告，然後再在 service Section 中啟用。例如：啟用 health_check Extension：
service:
extensions:
- health_check
完整的 Extensions 清單可參考 Core Repo 的 extension 與 Contrib Repo 的 extension。
為了監控和確保 Collector 服務運行正常，Collector 可以揭露其自身的 Telemetry Data，以供外部服務監控。目前可以提供 Logs 與 Traces 兩種資訊，例如揭露 Metrics：
service:
telemetry:
metrics:
level: detailed
address: 0.0.0.0:8888
瞭解了 Pipeline 之後，我們來看看 Connector。Connector 可以作為一個 Pipeline 的輸出，再成為另一個 Pipeline 的輸入，它就像是不同 Pipeline 之間的橋樑。例如，Forward Connector 可以達成轉到轉發跟匯流的效果：
receivers:
foo/blue:
foo/green:
processors:
attributes/blue:
attributes/green:
batch:
exporters:
bar:
connectors:
forward:
service:
pipelines:
logs/blue:
receivers: [foo/blue]
processors: [attributes/blue]
exporters: [forward]
logs/green:
receivers: [foo/green]
processors: [attributes/green]
exporters: [forward]
logs:
receivers: [forward]
processors: [batch]
exporters: [bar]
Pipeline 流程圖
完整的 Connector 清單可參考 Core Repo 的 connector 與 Contrib Repo 的 connector。
範例程式碼：22-otel-collector
啟動所有服務
docker-compose up -d
檢視服務
FastAPI App
Grafana: http://localhost:3000，登入帳號密碼為 admin/admin
點擊左上 Menu > Explore，左上 Data Source 選擇 Tempo，即可看到 Traces 資料
透過瀏覽器對 application 的 /chain 發送 Request，可以在 Trace 資訊中看到 app-a、app-b、app-c 互相呼叫的順序
或是使用 k6 發送 Request
k6 run --vus 1 --duration 300s k6-script.js
Prometheus: http://localhost:9090
{job="otel-collector"} ，可以看到 OpenTelemetry Collector 揭露的 Metrics關閉所有服務
docker-compose down
從上文我們可以明顯看出，OpenTelemetry Collector 在架構設計上與之前介紹過的 Fluent Bit 和 Vector 高度相似。它們基本上都遵循 「Input -> Processor -> Output」 的工作流程，因為本質上，這些工具都是擔任 Pipeline 的角色。雖然各家都開始著重於能同時處理 Metrics、Traces 和 Logs，但各自仍有其專精領域。像 OpenTelemetry Collector 在 Trace 的處理上是最強的，而且其 Input 主要以 OTLP 為主。相對地，Fluent Bit 和 Vector 則支援更多不同類型的 Input，並且偏向於處理 Log。
目前選擇這類工具時，建議還是要盡可能選擇各自專精的領域，因為多數工具在非專精領域的功能大多還在 Beta 階段。等這些工具日後成熟，可以再考慮是否需要切換統一使用一個，比較理想的方式是，優先選擇使用主流的格式，例如 OTLP 和 Prometheus。這樣在未來即使要更換工具，也不必擔心沒有合適的 Input 和 Output。
至此我們以經介紹完 Metrics、Logs、Traces 的生成、收集、儲存、使用四個階段，接下來我們將進入應用篇，介紹如何搭配使用這些 Observability Signals 發揮出綜效。
iThome鐵人賽
看影片追技術